-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fill out target-spec metadata for all targets #127265
Fill out target-spec metadata for all targets #127265
Conversation
Complete the metadata fields for all targets. Cargo will depend on this for checking whether a given target supports building the standard library.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @BoxyUwU (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
r? @Nilstrieb |
Corresponding Cargo change here: rust-lang/cargo#14183 |
thanks, this is cool. why is it a draft? |
as far as i understood, the target-spec metadata format isn't 100% final? That's the only reason for it being a draft. |
These commits modify compiler targets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some of the stds seem wrong to me (as in, things that probably should support std because the OS is supported have it as false), but I think it's fine to merge this for now.
that said, I don't think this data is ready for erroring -Zbuild-std yet, you should take another look over it and mark all those with an OS supported by std (like Linux) as supporting std if you wanna use this information in cargo for errors. for warnings it seems fine already.
i'm still gonna merge this, because most of it is good and this is clear progress.
thank your for doing all this work!
tier: None, | ||
host_tools: None, | ||
std: None, | ||
description: Some("ARM64 macOS (11.0+, Big Sur+)".into()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd expect these numbers to be out of date at some point before we fully migrate.. but that is probably ok. let's keep it as-is.
host_tools: None, | ||
std: None, | ||
description: Some("ARM64 macOS (11.0+, Big Sur+)".into()), | ||
tier: Some(2), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I want to remove the tier from here at some point but that's ok, we can always remove it later
@bors r+ |
…tadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry LINK cannot open a file |
…metadata, r=Nilstrieb Fill out target-spec metadata for all targets **What does this PR try to resolve?** This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the `-Zbuild-std=std` flag is passed ([see this issue](rust-lang/wg-cargo-std-aware#87). This functionality in Cargo is reliant on the output of `--print=target-spec-json`. **How should we test and review this PR?** Check that a given target-spec metadata has been updated with: ``` $ ./x.py build library/std $ build/host/stage1/bin/rustc --print=target-spec-json --target <target_name> -Zunstable-options ``` **Additional Information** A few things to note: * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build * There's no rush for this to be merged. I understand that the format for this is not finalised yet. * Related: rust-lang#120745
…kingjubilee Rollup of 3 pull requests Successful merges: - rust-lang#127020 ( Add classify and related methods for f16 and f128 ) - rust-lang#127265 (Fill out target-spec metadata for all targets) - rust-lang#127744 (std: `#![deny(unsafe_op_in_unsafe_fn)]` in platform-independent code) r? `@ghost` `@rustbot` modify labels: rollup
☀️ Test successful - checks-actions |
Finished benchmarking commit (adeb79d): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 699.842s -> 700.232s (0.06%) |
Fix "std" support status of some tier 3 targets rust-lang#127265 marked targets with empty "std" support status as no-std targets in target-spec metadata: > * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.) https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3 > The `std` column in the table below has the following meanings: > > * ✓ indicates the full standard library is available. > * \* indicates the target only supports [`no_std`] development. > * ? indicates the standard library support is unknown or a work-in-progress. > > [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata. The new status is set based on the following criteria: - Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl) - Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl taiki-e/rust-cross-toolchain@f3068b6), so I included them in the group below that means “work in progress” rather than in this group. - Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available. - Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported. r? Noratrieb cc `@harmou01`
Fix "std" support status of some tier 3 targets rust-lang#127265 marked targets with empty "std" support status as no-std targets in target-spec metadata: > * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.) https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3 > The `std` column in the table below has the following meanings: > > * ✓ indicates the full standard library is available. > * \* indicates the target only supports [`no_std`] development. > * ? indicates the standard library support is unknown or a work-in-progress. > > [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata. The new status is set based on the following criteria: - Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl) - Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl taiki-e/rust-cross-toolchain@f3068b6), so I included them in the group below that means “work in progress” rather than in this group. - Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available. - Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported. r? Noratrieb cc ``@harmou01``
Rollup merge of rust-lang#133867 - taiki-e:platform-support, r=Noratrieb Fix "std" support status of some tier 3 targets rust-lang#127265 marked targets with empty "std" support status as no-std targets in target-spec metadata: > * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.) https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3 > The `std` column in the table below has the following meanings: > > * ✓ indicates the full standard library is available. > * \* indicates the target only supports [`no_std`] development. > * ? indicates the standard library support is unknown or a work-in-progress. > > [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata. The new status is set based on the following criteria: - Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl) - Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl taiki-e/rust-cross-toolchain@f3068b6), so I included them in the group below that means “work in progress” rather than in this group. - Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available. - Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported. r? Noratrieb cc ``@harmou01``
What does this PR try to resolve?
This PR completes the target-spec metadata fields for all targets. This is required for a corresponding Cargo PR which adds a check for whether a target supports building the standard library when the
-Zbuild-std=std
flag is passed (see this issue. This functionality in Cargo is reliant on the output of--print=target-spec-json
.How should we test and review this PR?
Check that a given target-spec metadata has been updated with:
Additional Information
A few things to note: